Aspects of the present invention relate generally to the field of system development and test, and more specifically to event-driven simulation of electronics.
Simulation of hardware components can be modeled at various levels of abstraction using event-driven simulation. Processor models implementing Instruction Set Simulators (ISS) in combination with hardware simulators can be used to simulate cross-compiled embedded software, for example, an operating system (OS). A collection of hardware models running such embedded software is known as a Virtual Platform (VP). However, when developing VPs and the corresponding actual systems which they model, issues with incorrect or unexpected interactions between the hardware and software components of the system can occur. Debugging these issues is often complicated by VP environment limitations, which typically restrict observability and controllability of the hardware models and embedded software simulation. Furthermore, because a separate debugger is often required for each processor core, with the rapid expansion of the number of cores in modern platforms, connecting separate debuggers to each modeled processor is often not feasible.
Additionally, applications running on top of the embedded software may create unexpected errors and require verification and testing. However, application verification and testing is often done separately, and with application specific debuggers, typically requiring execution of a debugger application or debug server for each software application being tested. Furthermore, because these debuggers typically run on the same operating system on which the application is being tested, this can create atypical system conditions and reduce the effectiveness of the test and debug process.
Conventionally, to debug an issue which spans various levels of the hardware and software components of the system, a hardware simulator control interface is used to view and debug the hardware components of the system, a separate software debugger with its own user control interface is connected to each processor model to debug the bare-metal software of interest in the system and one or more debug servers must be run on any embedded OS to connect additional debuggers, each debugger having a control interface.
Using multiple debuggers, and therefore multiple control interfaces, can cause additional difficulties. For example, when a simulation is stopped at one control interface, other control interfaces can be either blocked, or may not have accurate state information if they are unblocked. Additionally, the user must switch between different tools and control languages to see the state of different aspects of a system controlled with multiple different interfaces. Furthermore, command scripting to reproduce debug scenarios is awkward and sometimes impossible, as it can require separate scripts for each control interface.
Additionally, when using multiple control interfaces, elements across multiple hardware states, bare-metal software states, OS process states and/or high level application states cannot be easily specified, retrieved, or identified. Then using these elements as part of a breakpoint condition or action is nearly impossible. Conventionally, a user must manually record needed software or hardware state information as it is available during a simulation and mentally or externally evaluate the condition of the simulation from the information recorded. This may require coordinating multiple breakpoints in different control interfaces. Similarly, in the conventional environment, a user must manually set breakpoints in order to step through the instructions of the modeled components.
Accordingly, there is a need in the art for a system to efficiently debug and analyze components of a virtual platform, including by allowing a user to control and observe the state of the various hardware and software components, including high-level application software, modeled in the virtual platform.
Additionally, there is a need in the art for a system that allows a user to step through the source code of the embedded software at various levels of the software stack as well as the source code representing the hardware models, as the modeled components are executed in the simulation.
Additionally, there is a need in the art for a system that allows a user to manage breakpoints, including by inserting breakpoints that stop the simulation and/or the embedded software running on the processor models and return to a control interface within the simulation to evaluate elements of the hardware and the software states or to perform other breakpoint operations.